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Abstract 


This  report  describes  the  development  of  a software 
life  cycle  costing  mcdel.  The  model  reduces  life  cycle 
cost  to  a function  of  three  parameters  which  are  in  turn 
functions  of  a number  of  factors  that  describe  the  software 
system.  A step-by-step  algorithm  is  presented  for  building 
the  model  from  raw  data.  The  model  is  exercised  as  an 
example  with  a small  amount  of  data.  Sensitivity  analysis 
is  used  to  help  select  the  most  salient  factors.  Brief 
descriptions  of  management  applications  and  recommendations 
are  presented.  Appendices  describe  sample  data  and  two 


computer  programs  used  to  develop  the  model. 
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An  Approach  to 
SOFTWARE  LIFE  CYCLE  COST 


MODELING 


I Introduction 


Motivation 

Life  cycle  costing  is  a technique  of  managing  systems. 

Decisions  are  made  based  on  the  long  range,  not  just 

immediate,  impact  on  cost.  Operation  and  maintenance  cost 

must  be  considered  as  well  as  cost  of  development  and 

procurement.  Alternatives  are  evaluated  in  terms  of  the 

resultant  life  cycle  cost  as  well  as  technical  and 

operational  factors.  The  cost  could  be  measured  in 

dollars,  time,  opportunity  lost,  or  any  number  of  other 

units.  Department  of  Defense  Directive  (DODD)  5000.28 

defines  life  cycle  cost  as: 

"...  the  total  cost  to  the  government  of 
acquisition  and  ownership  of  that  system 
over  its  full  life.  It  includes  the  cost 
of  development,  acquisition,  operation,  and, 
where  applicable,  disposal."  (Ref  1:8) 

There  are  two  very  important  reasons  for  using  the 
concept  of  life  cycle  costing.  The  first,  and  most  impor- 
tant reason,  is  that  life  cycle  costing  can  save  money. 

The  Department  of  Defense  spent  over  three  billion  dollars 
on  software  in  1976  (Ref  2:41)  up  from  one  billion  dollars 
in  1974  (ref  3:63).  This  figure  continues  to  grow  each 
year.  Any  technique  which,  for  a reasonable  cost,  will 
help  to  control  or  reduce  that  cost  should  be  applied  when 
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possible . 

As  early  as  1968,  the  Air  Force  Logistics  Command  used 
the  technique  of  life  cycle  costing  in  procurement  (Ref  1: 
38-40) . The  contract  for  T-38  aircraft  main  landing  gear 
tires  was  awarded  based  on  the  lowest  bid  for  cost  per 
landing.  Before  this  life  cycle  cost  procurement  was  used, 
the  T-38s  were  averaging  41  landings  per  tire.  After  the 
award  of  the  life  cycle  cost  contract,  the  average  number 
of  landings  per  tire  grew  to  104,  a 1 50f°  increase.  The 
same  technique  has  since  been  applied  to  electron  tubes, 
oscilloscopes,  hydraulic  filters,  and  more  with  resultant 
cost  reductions  of  several  millions  of  dollars.  However, 
the  literature  search  for  this  research  did  not  reveal  a 
single  application  of  life  cycle  cost  procurement  or  an 
application  of  life  cycle  costing  to  procurement  decisions 
in  the  case  of  software. 

If  dollar  savings  are  not  sufficient  to  justify  the 

use  of  life  cycle  costing  techniques,  there  is  further 

pressure  to  develop  and  apply  the  techniques  to  all 

acquisitions.  Air  Force  Regulation  800-11,  Life  Cycle 

Costing  (LCC),  directs  the  following: 

"The  Air  Force  will  to  the  maximum  practical 
extent,  determine  and  consider  life  cycle 
cost  in  the  various  dec.isions  associated  with 
the  development,  acquisition,  and  modification 
of  defense  systems  and  subsystems  and  in  the 
procurement  of  components  and  parts. (Ref  1:16) 

Knowing  that  life  cycle  costing  techniques  can  result  in 

significant  savings  and  that  they  are  required  by  regulation 

is  not  sufficient  unless  a model  or  methodology  exists  for 
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the  application  of  those  techniques  to  software  acquisition. 


Objectives 

The  objectives  of  this  thesis  effort  can  be  divided 
into  three  highly  interdependent  parts.  The  first 
objective  was  to  develop  a model  that  would  provide  for 
derivation  of  the  life  cycle  cost  of  a software  system. 

To  be  really  useful  for  planning  and  budgeting,  the  model 
should  provide  time  phased  allocations  of  resources  over 
the  life  cycle  of  the  system.  The  model  was  also  to 
provide  a vehicle  for  evaluating  the  effects  of  modern 
programming  practices,  such  as  structured  programming  and 
design,  on  the  life  cycle  cost  of  software.  This  would  be 
done  by  means  of  a sensitivity  analysis  of  the  resultant 
model . 

The  second  and  less  formidable  objective  was  to 
develop  a computational  algorithm  for  applying  the  model. 
The  algorithm  should  provide  a step-by-step  procedure  that 
will  inexorably  lead  to  the  computation  of  the  life  cycle 
cost  of  the  given  software  system. 

The  last  objective  was  to  uncover  enough  data  to  test 
the  model  and  demonstrate  the  use  of  the  computational 
algorithm.  This  objective  was  not  adequately  satisfied 
due  to  severe  limitations  on  the  availability  of  data. 


Limitations 

Data  availability  is  the  most  severe  limitation  to  the 
successful  modeling  of  software  life  cycle  costs.  Four 
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factors  contribute  to  the  scarcity  of  data.  The  first  and 
most  disastrous  is  that  the  data  is  often  simply  not 
collected.  Even  the  government,  which  is  notorious  for 
requiring  massive  amounts  of  data,  does  not  collect 
software  cost  data.  This  may  be  a result  of  the  cost  or 
impracticality  of  separating  costs  into  categories.  After 
all,  it  does  cost  money  and  time  to  account  for  expendi- 
tures of  resources,  especially  people's  time.  How  would 
an  engineer's  time  spent  working  on  data  communications  be 
allocated  between  the  software  handler  and  the  hardware 
bus  connections? 

The  second  factor  leading  to  the  scarcity  of  data  is 
a result  of  competition  among  contractors.  Proprietary 
interests  can  keep  software  development  organizations  from 
releasing  data  that  they  believe  could  give  their 
competitors  more  data  than  they  have.  If  the  data  were 
released,  there  is  always  the  fear  that  it  might  be  used 
against  the  releasing  organization  since  the  costs  reveal 
profit  margins. 

When  data  are  collected  and  reported,  the  reliability 
of  the  data  must  still  be  in  question.  The  collection 
method,  whether  self-reported  or  measured  over  the  shoulder, 
must  be  considered.  Biasing  must  almost  naturally  be 
assumed.  Raw,  objective  data  must  be  sought  out  to  avoid 
the  effects  of  unknown  massaging  by  possibly  biased 
reporters . 

The  researcher  must  still  be  wary  even  of  raw, 
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objective  data.  Consistency  should  be  the  watchword. 

Unless  all  of  the  data  sets  include  the  same  data  measured 
in  the  same  units,  it  could  be  impossible  to  draw  conclu- 
sions about  the  relations  between  the  two  life  cycles. 

For  instance,  comparing  the  sizes  of  two  software  efforts 
would  be  very  difficult  if  one  was  reported  in  lines  of 
higher  order  source  language  while  the  other  was  reported 
in  words  of  object  code. 

Because  of  the  potentially  extreme  complexity  of  the 
software  life  cycle  as  discussed  in  the  next  chapter,  it  is 
necessary  to  limit  the  model  to  a tractable  subset  of 
reality.  Specifically,  the  model  addresses  only  technical 

• 1 

manning  of  the  software  project  in  man-months  per  month. 

j 

This  limitation  implies  that  administrative  support, 
facilities,  and  computer  costs  are  omitted.  The  model 
also  ignores  operating  costs  under  the  assumption  that  the 
factors  under  investigation  affect  maintenance  and  not 
operating  costs.  Costs  to  enhance  or  add  capabilities  to 
operational  software  are  also  omitted.  These  types  of 

I# 

activities  should  be  separately  costed  on  their  own 
technical  merit  and  effect  on  life  cycle  cost  of  the  system. 

Other  limitations  on  the  model  are  made  apparent  at  the 
appropriate  point  in  the  remainder  of  the  text. 

. 


*3*'!rcr*TOr 


'W.wj* 


/ 

II  Software  Life  Cycle 

v* 

Life  Cycle  Description 

The  software  life  cycle  is  an  extremely  complex 
process.  The  process  can  be  divided  into  two  phases: 
development  and  operations  and  support.  This  is  a 
historical  breakdown  based  on  traditionally  separate 
organizations  being  responsible  for  the  two  phases  of  the 
life  cycle. 

Development . Air  Force  Regulation  800-14,  Management 
of  Computer  Resources  in  Systems  (Ref  4) , provides  an 
excellent  description  of  the  five  stages  of  the  development 
phase  as  depicted  in  Figure  1.  The  concept  and  analysis 
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Figure  1.  Stages  of  Software  Development  Phase 


stage  encompasses  most  of  the  activity  from  the  birth  of 
the  idea  that  led  to  proposing  the  software  system  to  the 


6 


/ 


preliminary  design  review  (PDR)  of  how  the  system  would  be 
constructed.  The  design  phase  refines  the  preliminary 
design  into  the  precise  module  requirements  presented  in 
the  critical  design  review  (CDR).  These  requirements  are 
put  into  the  computer  code  and  debugged  during  the  code 
and  checkout  stage.  The  test  and  integration  stage  begins 
when  the  programmers  turn  their  debugged  modules  over  to 
the  testing  group  and  strict  configuration  control  efforts 
begin.  Test  and  integration  includes  inter-module 
interface  testing  and  culminates  in  final  acceptance  tests 
(FAT)  that  insure  that  the  software  meets  the  original 
specifications  before  entering  the  installation  stage.  The 
final  qualification  tests  (FQT)  insure  that  the  software  is 
operating  as  advertised  at  the  operational  sites  before 
entering  the  operations  and  support  phase  of  its  life 
cycle . 

Operations  and  Support . The  operations  and  support 
phase  includes  four  types  of  activities,  shown  in  Figure  2. 


Figure  2.  Operations  and  Support  Activities 

The  most  obvious  activity  is  the  normal  production 
operation  in  which  the  software  performs  the  tasks  it  was 
designed  to  accomplish.  The  software  is  obviously  not 
always  in  an  operational  state  and  sometimes  requires 
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maintenance.  The  error  may  only  cause  the  system  to  be  in 
a degraded  mode  of  operation  or  could  bring  the  system 
down  to  a useless  state.  A third  activity  of  the  operation 
and  support  phase  includes  actions  taken  to  enhance  the 
software  system  either  by  improving  on  existing 
capabilities  or  adding  additional  desired  capabilities. 

The  final  activity  of  the  operation  and  support  phase  and 
of  the  entire  life  cycle  of  the  software  system  is 
decommissioning.  Although  this  would  seem  to  be  a trivial 
activity,  it  includes  a lot  of  planning  for  replacement 
and  backup  capability  and  often  a lot  of  contractual 
clean-up  to  bring  the  life  cycle  full  circle. 

Iterative  Complexity . Although  Figures  1 and  2 depict 
distinct  activities,  this  is  hardly  the  case  in  the  real 
world  of  software  systems.  Design  errors  can  be  discovered 
well  after  the  critical  design  review,  even  as  late  as  the 
installation  stage.  Even  the  boundary  between  development 
and  operations  is  not  very  distinct.  Analysis  and  design 
play  a large  role  in  enhancement  activities  in  particular. 
Figure  3 shows  a much  more  realistic  view  of  the  iterative 
relationship  of  the  activities  in  the  software  life  cycle. 

Model  Life  Cycle 

Simplifications . Two  major  simplifications  were  made 
to  reduce  the  complexity  of  the  software  life  cycle  process 
for  the  purpose  of  developing  this  model.  The  first  was 
to  reduce  the  concept  of  the  life  cycle  to  a smooth 
continuous  function  of  effort  rather  than  the  described 
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distinct  activities.  After  all,  what  is  the  value  of 
knowing  the  cost  of  the  design  stage  relative  to  the 
complexity  of  breaking  down  and  assigning  costs  to  each 
stage?  The  continuous  approach  allows  the  model  to 
allocate  resources  over  time  rather  than  to  an  activity. 
This  would  lend  itself  to  the  problems  of  planning  and 
budgeting.  A second  simplification  was  to  ignore  the  cost 
of  operations,  facilities,  administrative  support,  and 
hardware  since  these  are  somewhat  irrelevant  to  the 
objectives  of  this  research.  The  last  major  simplification 
was  not  to  consider  enhancement  activity  as  a part  of  the 
model  life  cycle.  Enhancement  of  software  in  truth  is  the 
development  of  a new  software  system  of  which  a portion 
already  has  been  completed.  As  was  mentioned  earlier, 
these  activities  should  be  costed  based  on  the  development 
of  a "new"  software  system. 

Cost  Units.  Further  simplification  resulted  from  the 
choice  of  man-months  as  the  unit  of  cost.  Although  not  a 
precise  unit,  the  man-month  could  be  statistically 
standardized.  Unlike  dollars,  inflation  has  no  direct 
impact  on  the  man-months  required  to  complete  a task. 
However,  learning  curve  effects  could  have  a deflating 
effect  on  man-months.  Except  for  the  least  complex, 
repetitive  operations,  the  time  required  to  do  a task  will 
generally  decrease  with  experience  due  to  learning. 

Another  reason  for  choosing  man-months  as  a unit  of  cost 
is  that  data  for  man-months  expended  on  a project  would  be 
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rather  easy  to  collect  and  is  easily  converted  to  dollar 
units  with  known  salary  scales. 


Ill  Life  Cycle  Cost  Model 
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Traditional  Cost  Models 

Traditionally,  cost  models  have  been  restricted  to 
either  the  development  phase  or  the  operation  and  support 
phase  of  a system's  life  cycle.  Even  the  few  models  that 
are  called  life  cycle  cost  models  reduce  one  phase  or  the 
other  to  a single  input  of  development  cost  or  support  cost 
as  an  amount  or  percentage  of  the  other  (Refs  5;  6;  7s  8; 
9).  In  the  literature  search  for  this  research  effort, 
there  were  no  examples  of  life  cycle  costing  of  software 
systems  and,  especially,  no  documented  operations  and 
support  models.  Several  modeling  techniques  are  available 
to  perform  life  cycle  costing  (Ref  10:15-17). 

Unit  Cost . The  unit  cost  method  is  particularly 
popular  in  hardware  cost  models.  This  method  simply  adds 
up  the  costs  of  the  pieces  of  the  system  to  derive  a system 
cost.  While  the  cost  of  a standard  gear  or  audio  amplifier 
may  be  easily  determined,  the  cost  of  a search  routine  or  a 
software  fast  Fourier  transform  is  not  so  well  known.  Unit 
costing  has  been  applied  to  software  where  the  size, 
measured  in  number  of  instructions,  is  multiplied  by  an 
average  cost  per  instruction  (Ref  10:21).  This  method  is 
often  called  decomposition  which  is  the  process  of  breaking 
the  system  into  ever  smaller  components  until  the  costs 
of  each  of  the  components  can  be  more  accurately  estimated. 

Analogy . This  method  relies  on  the  experience  of  the 
estimator.  If  the  person  or  group  making  the  estimate  has 
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had  a significant  amount  of  experience  with  the  type  of 
system  being  developed,  then  the  estimate  should  be  better 
than  if  they  had  less  experience.  The  use  of  Delphi 
techniques  falls  into  this  category  of  estimation  methods. 

Parametric . The  parametric  method  of  cost  estimation 
is  highly  dependent  on  the  availability  of  reliable  data. 
Parametric  modelers  attempt  to  select  those  parameters  of 
the  system  which  determine  the  cost  and  derive  a cost 
estimating  relationship.  The  cost  estimating  relationship 
is  an  equation  that  sets  cost  equal  to  some  function  of  the 
chosen  parameters.  The  single  most  effective  tool  for  this 
method  is  regression  analysis.  Typically,  in  software  cost 
estimation,  this  function  may  take  the  form  of 

c = a I (Ref  11;  12;  13)  (1) 

where  c = cost 

a = coefficient  parameter  of  the  model 

I = size  of  the  software  system  in  number  of  instruc- 
tions 

b = exponent  parameter  of  the  model 
Parametric  models  allow  the  user  to  enter  data  on  some 
metric  or  metrics  of  the  system  and  mathematically  compute 
an  estimate  of  the  cost.  The  model  presented  in  this 
thesis  is  a parametric  model. 

Life  Cycle  Cost  Function 

The  parametric  model  proposed  in  this  thesis  is 
similar  in  form  to  the  Rayleigh  manpower  equation.  The 
Rayleigh  function  as  a probability  density  function  has 


the  form 


f(t)  = Ate’'*-"2/2 


A form  of  this  function  was  applied  to  modeling  software 
development  costs  by  Putnam  (Ref  14) . The  model  that  he 
presented  took  the  form 


y'  = 2Kate 


-at 


(3) 


where  y'  = rate  of  expenditure  in  man-years  per  year 
K = total  effort  in  man-years  (difficulty) 
a = shape  parameter  (related  to  type  of  system) 
t = number  of  years  into  the  development 

This  function  graphically  portrays  the  manpower  applied  to 

a software  development  effort  as  shown  in  Figure  4. 


= 2Kate 


-at 


Figure  4.  Putnam's  Rayleigh  Model  for  Development  Costs 


Putnam's  data  was  collected  while  he  was  assigned  to  the 
United  States  Army  Computer  Systems  Command  and  primarily 
concerned  with  business  oriented  software  systems. 

Putnam's  data  was  budgetted  man-years  per  year  rather  than 
actual  man-years  per  year. 
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The  model  proposed  in  this  thesis  is  very  similar  to 
Putnam's  except  that  a third  parameter  has  been  added  to 
attempt  to  model  the  maintenance  tail  of  the  life  cycle  of 
the  software  system.  The  proposed  function  has  the  form 


-k  t2 

m(t)  = k^te  2 + k^  (4) 

where  m(t)  = manning  of  effort  at  time  t in  man-months 
per  month 

k^,  kg.  kj,  = parameters  of  the  function 

t = time  into  the  life  cycle  in  months 

Several  versions  of  this  model  were  investigated,  primarily 
diff erring  in  the  form  of  the  last  term.  Most  proved  to  be 
somewhat  unmanageable  mathematically.  Equation  4 is  easily 
integrated,  differentiated,  and  otherwise  manipulated  to 
allow  adequate  fitting  to  data  points.  This  model  produces 
a graph  very  similar  to  Putnam's  except  that  it  is 
displaced  upward  by  the  constant  parameter,  k^  (see  Figure 

5). 

The  graph  of  this  function  with  the  proper  parameters 
has  the  same  shape  as  the  budgetted  expenditures  of  effort 
for  software  development  and  maintenance  under  current 
policies  (see  Figure  5)*  The  manning  starts  out  low  when 
the  system  is  undergoing  conceptual  definition  and 
requirements  analysis.  The  manning  grows  rapidly  as  design 
and  coding  progress  and  starts  to  fall  off  as  the 
integrated  system  enters  testing.  After  installation  is 
complete,  the  manning  level  for  maintenance  is  pretty 
close  to  constant.  Each  software  system  is  generally 
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maintained  by  a distinct  group  of  programmers  that  are 
allocated  at  a nearly  constant  level  over  the  life  cycle 
of  the  system. 

The  Maintenance  Tail 

y 

To  some  people  it  would  seem  logical  that  maintenance 
manpower  requirements  would  decrease  over  time  due  to 
growth  in  reliability.  In  other  words,  as  programming  and 
design  errors,  "bugs",  are  found  and  corrected,  the  time 
to  the  next  error  that  makes  the  system  non-operational 
should  increase  through  the  maintenance  phase  of  the  life 
cycle.  Any  programmer  with  any  experience  maintaining 
software  systems  can  dispute  this  reliability  growth 
assumption.  When  errors  occur  and  maintenance  action  is 
taken,  at  least  three  things  can  happen.  First,  the 
actual  error  can  be  truly  corrected.  The  error  can  be 
corrected,  but  the  fix  includes  a new  error.  Or,  a change 
may  be  inserted  that  does  not  really  correct  the  error 

■ 

that  caused  the  program  to  be  non-operational.  So,  at 
best,  reliability  growth  is  a probabilistic  event  depending 
a lot  on  the  competence  of  the  maintenance  programmers. 

Likewise,  growth  in  maintainability  might  be  a poor 
assumption.  If  maintainability  is  defined  as  the  time  to 
return  a software  system  to  operational  status  once  an 
error  occurs  and  growth  in  maintainability  is  a decrease 
in  the  time  to  correct  an  error,  then  growth  in 
maintainability  night  again  seem  to  be  a logical 
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conclusion.  However,  several  factors  might  lead  another 
examiner  to  reach  the  opposite  conclusion,  decaying 
maintainability  or  increasing  time  to  correct  an  error. 
Personnel  turnover,  common  in  the  software  industry  not 
just  in  the  Department  of  Defense,  can  inhibit  ar.y  increase 
in  familiarity  with  the  system.  Patchwork  fixes  can  not 
only  introduce  new  errors,  but  also  complicate  the  finding 
of  other  errors  and  interface  problems.  Documentation  may 
decay  or  simply  not  exist  on  new  releases.  Less  than 
absolute  configuration  control,  especially  where  multiple 
versions  are  in  use  at  separate  sites,  can  easily  complicate 
error  identification  and  correction. 


Psychological  factors  can  also  control  manning  levels 
in  maintenance  organizations.  It  may  be  very  difficult  to 
convince  an  organization  responsible  for  the  maintenance 
of  large  software  systems  that  it  does  not  need  as  many 
people  as  it  originally  did  to  do  its  job.  If  the  system 
were  split  among  programmers  along  functional  boundaries, 
there  is  indeed  an  actual  dollar  cost  involved  in  training 
the  remaining  programmers  to  take  over  those  functions 
previously  maintained  by  the  excess  programmer. 

One  further  argument  for  accepting  the  compromise 
constant  manning  for  the  maintenance  tail  resulted  from  a 
discussion  with  the  people  setting  up  the  software 
maintenance  facility  for  the  F-15  aircraft  avionics  systems 
(Ref  15)-  In  determining  the  number  of  programmers  needed 
to  maintain  the  F-15's  avionics  software,  they  used  a 
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linear  model  of  the  form 


m 


s x r 
P 


(5) 


where  m = manning  requirements 

s = size  of  the  software  in  source  statements 
r = percent  of  software  recoded  per  year  (.05) 
p = programmer  productivity  (200  instructions  per 
month) 

The  implication  of  these  assumed  values  for  r and  p is 
that  maintenance  manning  is  constant  for  a given  system 
size  and  that 


ra  = 48000 

or  that  one  programmer  is  required  for  every  48,000  lines 
of  source  code.  This  suggests  that  there  might  he  an 
upper  limit  on  the  size  of  software  that  a single 
maintenance  programmer  can  keep  up  with  adequately.  The 
value  of  this  limit  might  be  determined  by  factors  such  as 
programmer  experience  or  the  modern  programming  practices 
used  to  produce  the  software,  structured  design  or 
modularization. 

The  only  way  to  verify  the  concept  of  the  constant 
maintenance  tail  is  to  collect  long  term  data  on  actual 
systems  and  compare  the  data  to  the  model.  Assuming  that 
the  data  exists,  the  next  pertinent  question  would  be  how 
to  build  the  model  from  the  data. 

Parameter  Evaluation 


In  order  to  evaluate  the  parameters  of  the  model,  k^, 


k2,  and  k^»  the  model  function  is  fit  to  the  data 

available.  Several  methods  were  available  to  do  the 
fitting.  All  of  the  methods  started  with  an  initial 
evaluation  of  the  maintenance  tail  parameter,  because  its 
value  is  in  fact  the  asymptote  of  the  curve  of  the 
function  as  is  obvious  from  Equation  7 below.  In 

-k?t2 

Lim  m(t)  = Lim  k.te  + k~  = k~  (7) 

t>oo  t>oo  1 J J 


consonance  with  the  arguments  presented  in  the  previous 
section,  k^  is  calculated  from  the  data  by  averaging  all 

the  values  for  manning  after  the  software  was  delivered, 


n 

m(ti) 

i=d+l 
n - d 


(8) 


where  n = number  of  data  points  available 

d = number  of  months  in  development  prior  to  delivery 
m(t^)  = actual  manning  during  month  t^ 

The  location  parameter,  k 2,  and  the  shape  parameter, 

k^,  can  now  be  determined  by  an  experimental,  trial  and 

error  technique.  The  technique  required  a lot  of  computing 
and  plotting  of  functions  on  top  of  actual  data  while 
adjusting  the  two  parameters,  k1  and  k2 , until  a 

reasonable  visual  fit  was  found.  In  order  to  expedite  the 
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process,  a computer  program,  LCCPLOT,  was  written  and  is 
included  as  Appendix  B.  A more  reasonable  approach  would 
be  to  directly  compute  estimates  of  k^  and  kg  from  the 
available  data. 

The  method  of  linear  least  squares  offers  one  means 
of  computing  the  parameters.  To  apply  this  technique,  the 
function  must  be  linearized.  This  can  be  done  by  moving 
k^  to  the  left  side  of  the  equation  and  taking  the  natural 

logarithm  of  both  sides  resulting  in  the  following: 

In  (m(t)  - k^)  = In  (k^  + In  (t)  - kgt2  (9) 

which  is  of  the  linear  form 

y = bQ  + b1g1(t)  + b2g2(t)  (10) 

One  major  drawback  of  this  method  is  that  should  k^  ever 

be  equal  to  m(t),  then  the  natural  logarithm  is  undefined. 
Applying  this  method  resulted  in  differences  between  total 
cost  in  man-months  from  actual  data  and  the  model  function 
of  as  much  as  ten  percent  for  the  data  available.  So, 
another  more  appropriate  method  was  sought. 

By  using  the  derivative  to  solve  for  the  maximum  of 
the  model  function,  the  parameter,  kg,  can  be  determined. 

The  derivative  evaluated  at  the  time  of  maximum  manning, 

t must  be  equal  to  0 as  shown  here: 

Hid  x 
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d m(t) 
dt 


k -^Vx  . 2k  k t2  e'k2%ax 
1 12  max 


= 0 (11) 


max 


°r  ^2  ~ OJ.2 


(12) 


2t 


max 


Since  t can  be  fixed  through  inspection  of  the  data,  k0 
max  c. 

is  determined.  In  the  application  presented  later,  imax 

is  the  time  at  which  the  maximum  manning  level  first  occurs 
in  the  data.  It  is  also  apparent  that  kg  is  a location 


parameter  determining  the  location  of  the  peak  of  the 
model  function. 

Assuming  that  kg  and  k^  have  been  determined,  k^  can 


be  determined  by  thinking  in  terms  of  the  purpose  of  the 
model,  that  is,  to  accurately  model  the  life  cycle  cost  of 
the  system.  But,  the  life  cycle  cost  of  the  system  is 
simply  the  integral  of  m(t)  over  the  life  cycle  of  the 
system  or 


mtlc)  = 


"lc 


m(t)dt  = 


2k, 


(1  - e lc)  + k3tlc 


(13) 


= LCC 


where  M(t)  = accumulated  cost  at  time  t in  man-months 
t^c  = number  of  months  in  the  life  cycle 

LCC  = total  life  cycle  cost  in  man-months 
When  working  with  the  data  available,  t,  is  replaced  by  t 

-L  C v 3. 

where  t is  the  number  of  months  for  which  data  are 

cX 
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available.  M(t  ) is  easily  computed  from  the  actual  data 

3. 

by  the  following: 

M(ta)  = / ,ni(t.)  (14) 

i=l 


And  now,  manipulating  Equation  13  yields 


ki  = 


2k2  (M(ta)  - kjV 


1 - e 


(15) 


which  determines  k^  in  terms  of  known  data. 

Using  Equations  8,  12,  and  15.  the  parameters  of  the 
model  function  can  be  reduced  to  numbers  and  the  function 
plotted  against  the  actual  data.  This  capability  is  also 
provided  via  the  computer  program,  LCCPLOT  (see  Appendix 
B).  This  method  makes  computing  the  parameters  of  the  life 
cycle  cost  function  straightforward  when  data  is  available, 
but  how  are  the  parameters  determined  for  unknown  software 
systems? 


Factor  Identification 

One  of  the  objectives  of  this  thesis  was  to  relate 
modern  programming  practices  and  management  decisions  to 
their  effects  on  the  life  cycle  cost  of  software  systems. 
An  appealing  assumption  is  made  concerning  these  factors 
and  the  parameters  of  the  life  cycle  cost  model  proposed 
here.  That  assumption  is  that  the  parameters  of  the  model 
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can  be  expressed  as  functions  of  a set  of  known  factors  of 
the  software  system  as  shown  here: 


^ = f (known  factors, 

fi> 

(16) 

2 = g(known  factors, 

fi> 

(17) 

^ = h (known  factors, 

fi> 

(18) 

One  further  simplifying  assumption  is  that  the  functions, 
f,  g,  and  h,  are  linear  combinations  of  the  known  factors. 
That  is,  the  functions  are  of  the  form 


n 


/ , 1 1 

i=l 


(19) 

(20) 

(21) 


Very  few  references  consider  factors  such  as  size  of  the 
software  to  be  linearly  related  to  cost,  however,  linearity 
is  assumed  here  for  simplicity. 

The  factors  chosen  for  analysis  must  meet  certain 
criteria.  The  first  and  most  practical  criteria  is 
availability.  The  factor  must  be  known  and  reported  along 
with  the  manning  data  on  the  system.  The  factors  must  be 
quantifiable.  Logical  ones  and  zeros  can  be  used  to 
indicate  the  use  or  non-use  of  given  practices.  Percentages, 

2^ 


counts,  and  measures  are  more  obviously  quantifiable  forms 
of  reporting  factor  values.  As  mentioned  in  the  intro- 
duction, consistency  of  definitions  and  measurement  units 
should  also  be  a strict  criteria.  One  other  criteria  is 
variability.  Unless  the  factor  varies  from  one  system  to 
the  next,  there  is  no  point  in  asking  questions  about  that 
factor.  If  all  the  data  comes  from  systems  written  in  the 
COBOL  language,  then  making  the  language  a factor  is  a 
useless  effort. 

Some  of  the  factors  that  can  affect  the  cost  of 
software  that  were  reported  and  found  in  the  literature 
search  have  been  compiled  and  regrouped  in  Figure  6.  Given 
sufficient  data  on  life  cycle  cost  and  factors  for  each  of 
the  systems,  the  resultant  systems  of  linear  equations  can 
be  solved  to  reveal  the  coefficients  of  the  model,  a^,  b^, 
and  c^.  The  linear  equations  can  be  expressed  in  matrix 

form  as 
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where  k^  = parameter  k1  evaluated  for  system  3 

m = number  of  data  sets  available 
f . . = value  of  factor  i for  system  3 
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n = number  of  factors  used  in  the  model 
a.  = coefficients  of  the  linear  function  relating 
the  parameter,  k^,  to  the  factors  used 

Similar  matrix  equations  can  be  written  for  the  other 
parameters,  k ^ and  k^,  where  b^  and  c^  would  replace  the  a^ 

as  the  coefficients  of  the  linear  function. 
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Figure  6.  Factors  That  May  Affect  Life  Cycle  Cost 

(Refs  12:15-16;  22(Vol  III):  5-7;  230-1-69;  14:42; 
16:7;  17:27-32) 


The  next  step  is,  of  course,  the  solution  of  this  set 
of  matrix  equations  for  the  coefficients  so  that  the  model 
can  be  used  to  predict  the  life  cycle  cost  of  a system  from 
only  the  factors  used  in  the  model.  In  other  words,  the 
goal  is  to  compute  the  function  parameters,  k^,  k^,  and  k^« 

for  a non-existent  system  using  estimates  or  known  values 
for  the  factors  used  in  the  matrix  equations.  If  the  number 
of  factors,  n,  to  be  used  in  the  model  is  greater  than  the 
number  of  data  sets  available,  m,  then  the  equations  can 
not  be  solved  for  the  coefficients.  If  n is  equal  to  m, 
then  there  is  a solution  to  the  matrix  equations  which  can 
be  found  using  Cramer's  Rule  assuming  that  the  factor 
matrix  is  non-zero.  When  more  data  sets  are  available  than 
factors  that  are  included  in  the  model  (m  greater  than  n) , 
then  the  method  of  least  squares  can  be  used  to  find  the 
best  (by  least  squares  standards)  fit. 

To  make  these  types  of  calculations,  the  digital 
computer  is  an  excellent  tool.  Appendix  C describes  a 
program,  LCCMODL,  that  was  written  to  implement  the  model 
presented  in  this  thesis.  It  accepts  the  data  sets 
(manning  and  factors),  computes  fitted  parameters,  solves 
the  matrix  equations  and  makes  predictions  of  function 
parameters  using  the  derived  coefficients  and  given  factor 
values.  I 


Sensitivity  Analysis 

The  purpose  of  performing  sensitivity  analyses  is  to 


gain  insight  as  to  which  variables  in  a problem  will,  when 
varied,  have  the  greatest  effect  on  the  final  result. 

With  respect  to  the  model  presented  in  this  thesis, 
sensitivity  analysis  is  used  to  identify  the  effects  of 
the  function  parameters  and  the  system  factors  on  the  life 
cycle  cost  of  the  software  system. 

Parameters . Two  methods  can  be  applied  to  measure 
the  sensitivity  of  life  cycle  cost  to  changes  in  the  values 
of  the  function  parameters.  The  first,  a manual  method, 
is  to  simply  vary  the  value  of  one  parameter  while  holding 
the  others  constant  and  observe  the  resultant  change  in 
cost.  Table  I shows  a sample  manual  sensitivity  analysis 
assuming  a life  cycle  of  200  months.  Figure  7 then  shows 
the  manning  curves  which  display  the  time  phased  effects 
of  variations  in  the  parameters  on  cost. 


Table  I 

Manual  Parameter  Sensitivity  Analysis 


Parameter 

kl 

Values 

k2 

k3 

Life  Cycle  Cost 

M(t=200) 

2.0 

.0002 

2.0 

5398.33 

1.9 

mm 

2.0 

5148.41 

2.1 

■29 

2.0 

5648.24 

2.0 

.0001 

2.0 

5308.42 

2.0 

.0003 

2.0 

5399-97 

2.0 

.0002 

1.9 

5378.33 

2.0 

. 0002 

2.1 

5418.33 

NTH 


The  method  of  partial  derivatives  provides  more 
information  about  the  sensitivity  of  the  life  cycle  cost 
over  the  life  cycle  of  the  system.  For  example,  the 
sensitivity  of  M(t)  with  respect  to  the  parameter,  , 

is  simply  the  partial  derivative  of  M(t)  with  respect  to 
k^  or 


a M(t)  _ 1 - e 
^k1  2k2 


> 0 


(23) 


which  is  greater  than  zero  for  all  positive  values  of  k2 


and  t.  This  implies  that  any  increase  in  the  parameter 
value  will  produce  an  increase  in  the  life  cycle  cost  of 
the  system.  Similarly,  the  partial  derivative  of  M(t) 
with  respect  to  k^  is 


|f^}-  = t > 0 (24) 

which  also  is  greater  than  zero  since  t is  always  greater 
than  zero.  The  partial  derivative  of  M(t)  with  respect  to 
k2  is  not  nearly  so  trivial  to  evaluate: 


3 M(t)  _ _ _^1 
3k3  2k2 


(1 


(25) 


Although  the  second  expression  is  obviously  positive  when 
kj,  k^ , and  t are  positive,  the  first  term  is  negative. 
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However,  for  significantly  large  t,  the  second  term  will  be 
dominated  by  the  first  and  make  the  value  of  the  partial 
less  than  zero.  And,  any  increase  in  k 2 will  cause  a 
decrease  in  the  total  life  cycle  cost.  It  is  interesting 
to  note  that  this  parameter  can  result  in  more  expenditure 
of  resources  during  development  (low  t)  and  less 
expenditure  during  the  maintenance  tail  (high  t) . 

Factors . From  this  information  about  the  parameters 
of  the  function,  it  is  possible  to  draw  direct  conclusions 
about  the  sensitivity  of  life  cycle  cost  to  the  values  of 
the  factors  chosen  for  the  model.  It  follows  from  the 
linear  relation  of  the  factors  to  the  parameters  that 


d k1 

1TTT 

ak2 

afi 


= a. 


= b. 


a k. 


*fi 


^ = 


c . 
1 


(26) 


(27) 

(28) 


The  sign  of  the  coefficients  will  indicate  the  direction  of 
the  effect  on  life  cycle  cost,  positive  implying  an 
increase  and  negative  implying  a decrease  in  cost  when  the 
factor  value  is  increased.  To  determine  the  relative 
magnitude  of  the  effects  of  each  factor,  the  partial 
derivatives  must  be  normalized  by  dividing  by  the  value  of 
the  parameter  or 
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(29) 


Going  back  to  the  sensitivity  of  life  cycle  cost  with 
respect  to  the  parameter,  k,  the  normalized  sensitivity  of 
life  cycle  cost  with  respect  to  the  factor,  f^,  due  to  its 

affect  on  the  parameter  k is  given  by 


2 M(t) 

afi 

M(t) 


5 M(t) 
2 k 


In  particular,  the  normalized  sensitivity  of  life  cycle 
cost  to  the  factor,  f^,  due  to  its  affect  on  parameter  k^ 


1 - e 
2k, 


Vic 


Vi 


Note  here  that  s,  r does  not  indicate  the  total 

sensitivity  of  cost  to  factor,  f ^ . It  does  not  include  the 

affects  of  factor,  f^,  on  cost  due  to  its  affects  on  the 

other  parameters,  kg  and  k^ . From  these  computations,  it 

can  be  determined  which  of  the  factors  in  a model  have  the 
greatest  effect  on  the  total  life  cycle  cost. 

Selectj on.  It  is  important  to  have  a tool  to 
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determine  which  factors  should  be  included  in  the  model. 


Sensitivity  analysis  provides  this  tool.  The  procedure  is 
to  build  the  model  with  the  available  data  and  a first  set 
of  desired  factors.  A sensitivity  analysis  of  the 
resulting  model  parameters  and  coefficients  can  reveal 
which  factor  is  least  influential  in  determining  life 
cycle  cost.  This  factor  can  be  replaced  by  another 
candidate  factor  in  a second  solution  of  the  model.  This 
procedure  can  then  be  continued  until  the  sensitivity 
analysis  shows  the  best  distribution  of  contribution  to 
the  life  cycle  cost.  Those  factors  that  most  dominate  the 
life  cycle  cost  should  be  reduced  in  effect  while  those 
that  contributed  the  least  should  increase  in  importance. 
Ideally,  the  magnitudes  of  contribution  of  each  of  the 
chosen  factors  would  be  equal.  In  order  to  properly 
demonstrate  this  process,  an  example  is  presented  in  the 
next  chapter  with  a formal  computational  algorithm. 


/ 

IV  Sample  Application 

Sample  Data 

The  data  used  for  this  sample  application  of  the 
modeling  algorithm  is  taken  from  a technical  report  from 
Sperry-Univac  Defense  Systems  (Ref  23) . The  raw  manning 
data  and  factors  for  each  of  four  softv/are  systems  is 
displayed  in  Appendix  A.  The  remainder  of  this  chapter 
is  a step-by-step  example  of  the  computational  algorithm 
that  will  implement  the  proposed  model. 

Computational  Algorithm 

Step  1.  The  first  step  of  the  algorithm  is  to  fit  a 
set  of  parameters,  k^,  and  k, , to  each  data  set. 

Equations  8,  12,  and  15  are  implemented  in  the  computer 
program,  LCCMODL,  described  in  Appendix  C.  Because  the 
data  available  for  this  example  is  for  development  only, 
special  arrangements  have  to  be  made  for  the  fitting  of  k^ . 

When  the  input  to  the  program  that  indicates  the  number  of 
development  data  points  is  the  same  as  the  total  number  of 
data  points,  the  program  expects  to  read  in  the  assumed 
value  of  k^  from  the  data  deck.  For  the  current  example 

these  values  were  computed  by  dividing  the  software  size  in 
total  source  instructions  by  48,000  as  suggested  by  the 
F-15  maintenance  example.  The  results  were  left  as 
fractions  rather  than  rounded  up  to  the  next  whole  man- 
month.  The  resultant  parameters  are  shown  in  Table  II. 
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Table  II 

Fitted  Parameters 


Program 

kl 

k2 

k3 

1 

.64969 

.000520 

1.875 

2 

2.24267 

.000297 

10.417 

3 

2.20299 

.002551 

.55^ 

4 

.79777 

.003472 

.274 

Step  2.  The  second  step  of  the  algorithm  is  to  select 
the  factors  to  be  used  in  the  first  attempt  at  the  model. 

In  order  to  verify  the  usefulness  of  the  model  only  the 
first  three  data  sets  will  be  used  to  build  the  model. 

This  means  that  only  three  factors  can  be  included  in  the 
model  (n<m,  see  Chapter  III).  The  following  three  factors 
were  chosen  at  random  for  the  first  round: 

1.  percent  HOL  (higher  order  language) 

2.  programmer  qualification  (combines 
education  and  experience) 

3.  development  on  target  hardware 

Step  2‘  The  next  step  is  to  take  the  fitted  parameters 
and  known  factors  and  solve  the  matrix  Equations  21  for  the 
model  coefficients,  a^,  b^  and  c^  (i=l,2,3).  This 

calculation  is  also  available  in  the  computer  program, 
LCCMODL,  as  a call  on  a subroutine  that  solves  the  system 
of  linear  equations.  The  results  of  this  first  attempt  at 
the  model  are  shown  here: 

kj  = 2.649  (?°  HOL)  + .013  (PROG  QUAL) 

- .853  (DEV  ON  TGT)  (32) 
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k2  = .000233  (?5  HOL)  + .000043  (PROG  QUAL) 

- .001052  (DEV  ON  TGT)  (33) 

k3  = 13.6714  (%  HOL)  - .1066  (PROG  QUAL) 

+ .8356  (DEV  ON  TGT)  (34) 

A quick  check  on  the  model  is  to  now  use  the  coefficients 
to  predict  the  values  of  the  parameters  to  fit  the  fourth 
set  of  data.  The  results  of  the  prediction  are  k^  = 

3.6975,  k2  = .003276,  and  k^  = 4.8910,  not  very  close  to 

the  values  presented  in  Table  II. 

Step  4.  The  fourth  step  of  the  algorithm  is  to 
evaluate  the  relative  contribution  of  each  factor  to  the 
life  cycle  cost  by  means  of  sensitivity  analysis.  The 
computer  program  LCCMODL  does  these  computations  using 
Equation  30  (see  Appendix  C).  The  appendix  includes  the 
results  for  this  set  of  factors  as  a sample.  Table  III 
shows  the  results  of  these  calculations  for  the  first  set 
of  data.  Factor  2,  programmer  qualification,  turns  out  to 


Table  III 

Sensitivity  Analysis  1 


have  the  least  significant  effect  on  life  cycle  cost.  The 
procedure  is  then  to  select  another  factor  to  take  its 
place  and  reaccomplish  the  sensitivity  analysis.  The 
factor  chosen  to  replace  programmer  qualification  is 
whether  or  not  modular  design  was  employed  to  develop  the 
software  system.  The  results  of  the  sensitivity  analysis 
of  this  combination  for  the  first  set  of  data  are  shown  in 
Table  IV.  This  process  can  be  repeated  over  and  over  until 


Table  IV 

Sensitivity  Analysis  2 


Parameter 

k 

Fac 

1 

tors 

2 

3 

ki 

2.50966 

- .328914 

.788334 

k2 

.43868 

- .791454 

- 3.29572 

k3 

2.80248 

- .689697 

- 1.37444 

the  modeler  is  satisfied  that  he  has  an  adequate  model  of 
the  data  at  hand,  perhaps  testing  the  model  by  allowing  it 
to  predict  the  parameters  of  another  data  set  not  used  to 
build  the  model.  The  results  here  for  the  fourth  data  set 
are  k1  = 3.42960,  k2  = .00237932,  and  k ^ = 7.13554.  Again, 

the  predicted  values  are  not  very  close  to  the  fitted 
parameters  in  Table  II.  In  fact,  the  deviation  is  greater. 

Step  The  final  step  in  the  computational  algorithm 
is  really  the  final  objective  of  the  process.  Assuming 
that  the  model  has  been  built  and  verified  by  checking 
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against  known  data,  it  can  be  used  to  predict  the  necessary 
manning  requirements  for  unknown  systems.  It  must  be 
assumed  that  the  factors  used  in  building  the  model  can 
be  reasonably  estimated  when  the  system  does  not  yet  exist. 
Estimating  the  factors,  such  as  size,  can  be  nearly  as 
difficult  a task  as  estimating  the  cost  was  before  the 
model  was  applied. 

Summary.  As  a summary,  Figure  8 lists  the  five  steps 
of  the  computational  algorithm. 


Step 

Action 

1 

fit  parameters  to  data 

2 

select  factors  to  include 

3 

solve  for  model  coefficients 

4 

perform  sensitivity  analysis 

5 

predict  parameters  of  unknown 
system 

Figure  8.  Computational  Algorithm 
Conclusions 


The  calculations  shown  in  this  chapter  are  only 
intended  to  act  as  a sample  format  of  how  the  computational 
algorithm  is  to  be  applied.  There  are  many  variations  in 
combinations  of  factors  that  could  be  tested.  It  is  clear 
from  the  inability  of  the  two  iterations  shown  here  to 
accurately  predict  the  parameters  of  the  fourth  data  set 
that  the  model  needs  more  refinement.  Whether  this  is  the 
result  of  an  inadequate  model,  inadequate  data,  or  poor 
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choice  of  factors  is  still  a matter  of  conjecture.  The 
two  iterations  presented  here  represent  the  best  results 
of  about  a dozen  trials  judged  by  predictive  capability. 


. 
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V Management  Applications 

The  model  presented  in  this  thesis  could  provide  a 
direct  means  to  evaluate  the  impact  of  current  and  future 
programming  or  management  practices  on  the  life  cycle  cost 
of  systems.  The  computational  algorithm  for  building  the 
model  and  the  computer  programs  presented  provide  the 
manager  some  significant  tools.  Of  course,  any  use  of  this 
model  should  be  preceded  by  adequate  data  collection,  model 
validation,  and,  if  necessary,  significant  modification. 

Pre-Contract  Applications 

Preliminary  life  cycle  costing  of  software  system 
proposals  before  entering  development,  while  not  very 
accurate,  can  be  used  in  evaluating  proposals.  The  request 
for  proposal  should  specifically  call  for  the  values  of  the 
factors  to  be  used  in  the  model.  The  factors  must  be  very 
specifically  defined  and  quantified  in  the  same  way  on  each 
proposal . 

In  a more  general  sense,  the  model  has  by  indicating 
whether  the  affect  of  a given  factor  increases  or  decreases 
life  cycle  cost  shown  how  the  factors  should  be  managed. 
Factors  that  increase  the  life  cycle  cost  should  be  avoided 
or  at  least  controlled.  Factors  that  help  to  reduce  life 
cycle  cost  should  be  encouraged  or  required  contractually 
or  by  regulation.  This  information  could  be  available  from 
the  construction  of  the  model  before  a contract  was 
awarded . 
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Development  Applications 


After  the  contract  is  awarded,  a software  development 
manager  can  continue  to  use  the  derived  model  as  a planning 
and  checking  tool.  Many  studies  have  been  performed  to 
investigate  the  percentage  of  development  effort  involved 
in  the  five  stages  of  the  software  development  phase  (see 
Table  V).  Using  these  percentages,  or  others  generated 


Table  V 

Proportion  of  Development  Effort  by  Stage 


Stage 

Reference  - number  and 

page 

18: B-3 

12:  28 

14: 171 

14: 1?1 

14: 171 

Ave 

Concept  & Analysis 

.05 

.20 

.20 

.20 

.140 

Design 

• 31 

.16 

.20 

.20 

.224 

Code  & Debug 

.23 

.16 

.25 

.24 

.246 

Test  & Integration 

.25 

.19 

.27 

.20 

.20 

.222 

Installation 

.10 

.22 

.21 

.15 

.16 

.168 

for  his  particular  case,  the  manager  could  check  his 
expenditures  of  manpower.  The  time  to  the  end  of  each  stage 
can  be  calculated  as  that  time,  t,  at  which 

M(t)  = p • M(td)  (35) 

where  p = percentage  of  development  effort  for  stage 
M(td)  = total  development  cost 

d = number  of  months  in  development 

In  addition,  a plot  of  the  model  manning  curve  and  the 
actual  expenditure  of  manpower  can  be  compared  with  limits 
set  to  trigger  an  in-depth  investigation  of  gross  deviations 
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from  the  planned  course. 


1 


Maintenance  Applications 

The  comparison  of  actual  and  predicted  manpower  needs 
during  the  maintenance  phase  of  the  life  cycle  would  be  one 
important  application  of  this  model.  Because  the  lack  of 
data  led  to  the  flat  maintenance  tail  assumption,  there  is 
little  that  can  be  done  to  increase  the  value  of  the  model 
other  than  to  collect  data  to  verify  or  modify  the  tail  of 
the  model.  In  all  stages  of  the  life  cycle  of  a system, 
data  should  be  compared  to  the  predicted  manning  levels. 
When  deviations  occur,  any  factors  that  might  explain  the 
deviation  should  be  reported  and  perhaps  applied  in  a 
re-building  of  the  model.  A centralized  point  for  software 
data  collection  would  be  invaluable. 


1 
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VI  Recommendations 

Data 

Collection.  By  far  the  most  important  recommendation 
to  be  made  is  that  data  on  the  software  life  cycle  costs  be 
collected  and  made  available  to  investigations  such  as  this. 
This  is  hardly  a new  recommendation,  but  it  bears  repeating 
for  emphasis  (Refs  19:92;  20:3-2).  Without  data  to  test, 
estimate  parameters,  verify,  and  validate  the  model  and 
assumptions,  the  parametric  approach  really  provides  no 
extra  insight  to  help  control  softv/are  costs.  Maintenance 
data  was  found  to  be  especially  lacking  during  this  effort. 

It  is  important  here  to  note  the  difference  between 
budgetted  and  actual  costs  even  in  man-months.  Because 
three  people  are  assigned  to  maintain  a softv/are  system 
does  not  mean  that  it  actually  took  three  man-months  of 
effort  to  maintain  the  system  during  a given  month. 
Considering  the  growing  trend  to  in-house  maintenance  of 
software  systems  in  regional  centers,  it  may  well  come  to 
pass  that  maintenance  programmers  could  be  shared  between 
systems,  i.e.,  that  maintenance  effort  may  be  budgetted  in 
fractions  rather  than  whole  numbers  of  man-months.  The 
sharing  could  be  done  on  the  basis  of  areas  of  expertise 
such  as  search  techniques,  statistical  applications,  or 
specialised  interfaces.  For  instance,  an  expert  in  data 
filtering  could  be  shared  by  several  systems.  The  only 
obvious  solution  to  the  lack  of  data  problem  is  to  require 
that  data  be  collected  and  made  available  by  regulation 
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for  in-house  projects  and  as  a deliverable  item  for 
contracted  work. 


Standardization.  If  cost  reporting  is  to  be  required, 
the  reporters  must  be  fully  aware  of  exactly  what  they  are 
to  report.  In  other  words,  standards  must  be  established. 
Definitions  of  terms  must  be  specific.  Structured 
programming  must  mean  the  same  thing  to  all  reporters  of 
data.  Units  of  measurement  must  be  consistent  from  project 
to  project.  Efforts  have  been  made  as  early  as  1966  (Ref 
21)  to  specify  cost  reporting  elements  and  were  repeated 
in  1976  (Ref  13)-  More  recently,  1976  to  1977i  a major 
study  was  commissioned  by  the  Rome  Air  Developmert  Center 
to  generate  recommendations  for  a data  collection  system 
to  establish  a repository  for  data  to  be  used  in  studying 
productivity,  reliability,  and  cost  of  software  (Ref  22). 
This  represents  at  least  one  step  in  the  right  direction. 


Follow-on  Modeling 

Every  researcher,  at  least  subconsciously,  wants  his 
work  to  be  used  and  continued.  In  the  case  of  this 
modeling  approach,  there  are  indeed  a lot  of  things  left 
to  be  done.  Before  accepting  or  rejecting  the  model,  it 
needs  to  be  given  adequate  testing  as  data  becomes  avail- 
able. Should  +ve  data  indicate  that  the  model  provides 
inadequate  results  for  accurate  prediction,  several 
modifications  can  be  made.  One  modification  would  be  to 
change  the  form  of  the  model  function  with  either  more  or 
fewer  parameters.  Another  more  challenging  route  might  be 
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to  explore  the  effects  of  non-linear  factors.  These 
modifications  and  more  yet  to  be  conceived  of  could  lead 
to  a useful  life  cycle  costing  tool  for  the  production  and 
maintenance  of  software  systems. 

Other  Applications 

Although  there  are  those  in  the  software  business  that 
still  insist  that  programming  is  an  art  and  bears  no 
resemblance  to  any  field  of  hardware  engineering,  there 
are  others  that  believe  software  engineering  people  have 
wasted  considerable  valuable  time  in  re-inventing  the  soft- 
ware wheels.  Most  everyone  will  concede  that  there  are 
differences  between  computer  programs  and  radars,  but  do 
these  differences  conceptually  amount  to  more  than  the 
differences  between  radars  and  automobiles?  While  working 
with  this  modeling  approach,  I was  struck  by  the  similarity 
of  the  manning  curve  for  software  systems  and  that  I 
conceived  would  be  applicable  to  hardware  systems.  With  a 
different  set  of  factors,  could  the  same  approach  be  used 
to  model  hardware  systems  or,  for  that  matter,  any  research 
and  development  effort? 
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A Sample  Data 

The  data  used  in  the  sample  calculations  of  Chapter 
IV  was  provided  by  Sperry-Univac  Defense  Systems  in  a Home 
Air  Development  Center  sponsored  technical  report  (Ref  23: 
1-31).  The  data  tabulated  in  Table  A-I  is  the  manning 
data  for  the  four  software  systems  reported  in  the  report. 

Table  A-I 

Sperry-Univac  Manning  Data 


5 

10 

5 

5 

13 

8 

5 

13 

8 

5 

15 

10 

5 

15 

12 

5 

15 

14 

5 

25 

16 

5 

26 

19 

5 

25 

20 

5 

34 

21 

5 

34 

22 

5 

34 

22 

10 

40 

22 

10 

40 

23 

10 

40 

22 

10 

45 

22 

in 

46 

22 

HI 

45 

19 
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49 

17 

15 

49 

14 

15 

49 

13 

15 

52 

12 

15 

53 

11 

15 

53 

10 

15 

56 

8 

16 

56 

7 

16 

56 

6 

16 

60 

4 

16 

60 

4 

16 

60 

3 

Month 
4 | 1 


31  17 

32  17 

33  17 

34  17 

35  17 

36  17 

■ 37 

4 38 

4 39 

4 4o 

4 41 

5 42  | 8 

5 43 

5 44 

5 45  , 

5 46  | 8 

5 47 

5 48 

5 49 

5 50  8 

5 51  8 

5 52  8 

5 53  8 

5 54  8 

5 55  8 

5 56  8 

' 57  8 

58  8 

59  8 

60  7 


Program  Month  Program 
2 | 3 I 4 j 1 | 2 ( 3 


61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
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The  units  are  man-months  per  month.  Table  A-II  shows  the 
factor  data  available  on  the  four  systems  also  found  in 
the  technical  report. 


Table  A-II 

Sperry-Univac  Factor  Data 


Factor 

P 

1 

rogram 

2 

3 

4 

Size  in  delivered  source 

90000 

500000 

26600 

13150 

Real-time  application 

1 

l 

1 

1 

Top-down  structured  design 

0 

0 

1 

1 

Structured  coding 

0 

0 

0 

1 

Memory  constraint 

.50 

.50 

.52 

.50 

Percent  HOL  used 

38 

99 

53 

100 

Programmer  qualification 
education  and  training 

39-0 

37.1 

62.8 

82.4 

Developed  on  target  machine 

1 

l 

0 

0 

Pages  of  documentation 

8059 

27014 

3507 

2259 

Command  and  control 
application 

1 

1 

1 

1 

Modular  design 

0 

0 

1 

1 

Program  librarian 

1 

0 

1 

1 

Structured  narative 

1 

0 

0 

1 

Flow  Charts 

1 

1 

1 

1 
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B Life  Cycle  Cost  Plotting  Program 


In  the  early  stages  of  this  research  effort  it  was 
obvious  that  it  would  be  necessary  to  graphically  display 
the  data  used.  This  program  was  the  result  of  that  need. 

It  will  read  in  the  raw  data  in  man-months  per  month, 
properly  scale  the  axes,  and  plot  the  data  versus  time 
into  the  life  cycle  using  squares  at  each  data  point. 

Figure  B-l  shows  a plot  of  the  first  set  of  data  listed  in 
Appendix  A. 

As  the  form  of  the  function  to  model  the  software  life 
cycle  costs  was  being  formulated,  it  was  necessary  to 
compare  the  plots  of  the  actual  data  with  that  computed 
from  the  function.  This  capability  was  added  in  such  a 
way  that  the  program  will  plot  any  number  of  computed 
curves  on  the  same  axes  as  the  actual  data.  This  capability 
is  demonstrated  in  Figure  B-2. 

The  program  listing  is  provided  as  it  was  implemented 
on  a Control  Data  Corporation  6600  computer  using  available 
CALCOMP  routines  for  on-line  plotting.  Figure  B-3  shows  a 
sample  data  deck  for  plotting  actual  data  against  two 
computed  curves.  Each  sequential  curve  is  given  a different 
symbol  to  be  plotted  at  each  point  from  the  table  of  symbols 
numbered  1 to  13  in  the  CALCOMP  user  Manual  (Ref  24:47). 
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C Life  Cycle  Cost  Model  Program 


This  program  was  written  to  perform  the  tedious  and 
complex  computations  used  in  the  computational  algorithm 
for  building  the  model  presented  in  this  thesis.  The 
program  performs  all  the  steps  of  the  algorithm  except 
selection  of  factors  and  iterating  the  third  and  fourth 
steps.  The  program  reads  in  the  data  (manning  and  factors), 
fits  function  parameters  to  the  data,  solves  the  matrix 
equations  for  the  model  coefficients,  calculates  the 
sensitivities  for  each  data  set,  and  predicts  the  function 
parameters  for  systems  from  known  factors. 

Figure  C-l  shows  a sample  data  deck  for  use  with  this 
program.  The  following  pages  are  a listing  and  sample 
output  from  the  program  using  all  four  of  the  data  sets 
listed  in  Appendix  A and  four  factors.  The  predictions 
are  for  the  same  four  data  sets.  The  data  set  fitted 
parameters  and  predicted  parameters  are  equal  since  the 
matrix  equations  are  fully  determined  by  the  four  data 
sets . 
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PROGRAM  LCCMOOL (INPUT, OUT PUT, TAPE4= INPUT, TAPt5=OU7 PUT) 


M 

It 

It 

•If 

« 

It 

« 

It 

It 

It 

It 

« 

It 

It 

If 

If 

If 

If 

If 

It 

It 

It 

It 

* 

•If 

•* 

« 

« 

« 

* 

It 

It 

It 

* 

CO 

m 

It 

»— 

3 

O 

X 

it 

♦ 

CO 

X 

2 

3 

« 

« 

3 

* — 

3 

< 

H- 

3 

it 

It 

LJ 

3 

3 

3 

X 

ic 

It 

o 

3 

CO 

<1 

X 

*— 

3 

« 

« 

OJ 

♦— 

2 

JL 

UL. 

* — 

X 

« 

♦ 

3 

3 

3 

u- 

« 

It 

3 

CO 

a 

— 

3 

3 

O 

it 

« 

>~ 

►— 

X 

3 

3 

3 

ic 

♦ 

O 

3 

3 

<1 

X 

3 

CO 

2 

< 

« 

CL 

u_ 

3 

3 

y- 1 

<1 

« 

* 

3 

2 

O 

CO 

3 

2 

ic 

It 

u. 

*—> i 

3 

CO 

2 

3 

*» 

it 

* 

•— * 

♦ — 

x 

< 

•— \ 

— » 

• — 

ic 

♦ 

-J 

3 

2 

►— 

3 

3 

■« 

— % 

It 

X 

O 

3 

CO 

»— < 

10 

if 

rO 

« 

UL 

♦— 

X 

X 

»— 

u. 

♦ 

It 

3 

1 

r 

►— 

3 

a- 

<£ 

it 

in 

It 

2 

3 

X 

3 

*— 

• 

•« 

o 

♦ 

3 

• 

< 

f— 

X 

‘ — 

3 

< 

V 

it 

in 

♦ 

'3 

CO 

co 

2 

3 

3 

3 

3 

it 

3 

N— > 

It 

3 

*— « 

>~ 

v-J 

*— 

it 

<1 

* 

CD 

CO 

CO 

3 

X 

CO 

•K 

3 

«c 

x 

13 

•— « 

v. 

3 

r 

3 

>- 

It 

o 

•n 

X 

If 

T* 

3 

CO 

r 

f— 

< 

CO 

1C 

o 

w 

< 

* 

•3 

V— 

< 

X 

►— 

• — 

3 

n 

OJ 

JO 

iC 

*o 

X 

►— 

f— 

3 

«h 

2 

K 

% 

» — ' 

X 

« 

►— 

>- 

<1 

CO 

♦— 

X 

£ 

K 

JO 

3 

jC 

•— < 

♦ 

X 

O 

u. 

• 

3 

o 

3 

If 

v-^ 

w 

* 

►— 

3 

<. 

o 

CO 

JL. 

2 

♦: 

3 

<*s 

'“•V 

CO 

It 

2 

2 

*— 

V— 

3 

« 

<3 

JO 

3 

t — 

It 

aJ 

»— ♦ 

CO 

3 

< 

»— 

< 

•to 

y 

it 

3 

w 

3 

co 

If 

X 

3 

3 

3 

3 

A— 

►— < 

2 

•« 

f— 

JO 

'X 

If 

<x 

f— 

* 

UJ 

3 

3 

3 

<- 

CO 

IC 

3 

w 

X 

3 

3 

It 

3 

UJ 

>- 

3 

o 

3 

>• 

3 

< 

CO 

2 

2 

c 

It 

CL 

*— 

3 

3 

X 

3 

3 

x 

« 

* 

X 

CO 

< 

V 

3 

•* 

r 

2 

X 

♦— 

X 

X 

< 

•— 

It 

r-s 

3 

JO 

X 

3 

*-N 

2 

It 

►— « 

aJ 

<; 

3 

3 

3 

■3 

It 

JO 

i — 

3 

X 

~T 

II 

* 

CO 

3 

3 

<. 

< 

X 

« 

w 

3 

n 

♦— 

*— t 

•-A 

It 

O 

3 

♦— 

3 

•iJ 

3 

2 

If 

CO 

< 

V ' 

3 

*“N 

— 

V 

II 

It 

l — 

x 

3 

3 

X' 

>- 

3 

n 

>— 

3 

CO 

<t 

*— » 

II 

,-v 

3 

•If 

CL 

O 

X 

X 

»— 

It 

X 

3 

W 

—1 

3 

•— * 

It 

o 

to 

3 

3 

3 

3 

►— » 

CO 

n 

O 

3 

CO 

w 

/~N 

■* 

•3 

’-O 

X 

< 

*— 

U- 

>• 

X 

It 

2 

S'. 

< 

2 

« — 

CO 

CO 

3 

•If 

CO 

X 

3 

♦— 

3 

> * 

3 

It 

V 

w 

3 

JO 

2 

X 

►— 

3 

fc— 

% 

•If 

3 

3 

< 

X 

CO 

— 

L~ 

It 

CO 

*— 

«. 

c 

2* 

X 

3 

—4 

♦ 

♦— 

3 

o 

X 

3 

X 

*— * 

3 

* 

uo 

♦ — 

JO 

2 

3 

* — t 

< 

* — ■ 

* 

CO 

co 

*— 

p 

o 

— 

3 

-0 

2 

It 

Sm* 

3 

w 

CO 

CO 

V 

- T 

V—, 

X 

CO 

CO 

♦ 

*— « 

>- 

3 

3 

CO 

2 

<X 

If 

CO 

< 

JO 

co 

►— 

•— 

/“S 

• 

3 

2 

— 

X 

It 

CO 

n 

X 

>- 

3 

3 

X 

*• 

•— 

3 

• — ' 

X 

3 

3 

r-4 

3 

<5 

to 

r— 4 

3 

2 

If 

X 

3 

CO 

CO 

r 

CO 

•c. 

« 

X 

a 

* 

3 

CO 

CO 

CO 

W 

3 

3 

►— 

W 

CO 

h- 

It 

< 

•3 

3 

3 

3 

<i 

K 

2 

» — 

CO 

*— 

2 

CO 

• 

►— 

3 

o 

2 

3 

«* 

x 

X 

3 

3 

X 

3 

If 

< 

3 

v 

►— 

/“»s 

3 

< 

■~s 

<1 

It 

o 

<x 

■C 

X 

3 

UJ 

< 

X 

3 

« 

2 

2 

2 

2 

f — 

CO 

X 

►— < 

<1 

3 

— • 

< 

— ^ 

-A. 

It 

o 

*— 

< 

co 

X 

►— 

3 

If 

O 

3 

< 

2 

II 

2 

w 

»— 

W 

z 

JO 

II 

w 

■« 

X 

• — 

x 

>■ 

3 

►— 

« 

*— « 

r— » 

— « 

►— 4 

3 

V 

*— • 

CO 

w 

V 

*— M 

It 

CL 

u 

<3 

o 

a 

3 

% 

3 

It 

CO 

CO 

CO 

CO 

It 

it 

) — 

CO 

■AC 

It 

3- 

►— 

It 

* 

3 

X 

X 

X 

3 

3 

— * 

— « 

Ik 

X 

Z 

2 

2 

o 

X 

»— 

< 

o 

•If 

co 

co 

3 

►— < 

X 

*— 

3 

o 

If 

3 

3 

3 

3 

•— i 

o 

,3 

X 

X 

2 

3 

3 

X 

ru 

2 

* 

—A 

3 

r 

3 

X 

• — 

3 

3 

4. 

X 

X 

J. 

X 

< 

w 

2 

<c 

<? 

-*4 

X 

<i 

« 

X 

Ul 

X 

a.: 

X 

3 

X 

If 

*— « 

*— « 

*— * 

►— < 

O 

3 

3 

3 

3 

II 

3 

3 

‘3 

3 

3 

3 

« 

— 

O 

X 

X 

*— 

< 

o- 

X 

X 

If 

3 

o 

o 

<. 

X 

3 

X 

r — 

2 

X 

«X 

tr 

3 

3 

X 

* 

« 

3 

It 

It 

X 

♦ 

It 

* 

* 

K 

If 

It 

It 

« 

it 

It 

« 

* 

It 

« 

If 

it 

« 

K 

if 

it 

It 

* 

•It 

■* 

* 

H 

« 

If 

« 

41 

« 

It 

o 

o 

3 

o 

3 

3 

3 

3 

3 

3 

3 

3 

3 

c 

c 

c 

c 

3 

»— A 

OJ 

58 


THIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
FROM  COPY  FURNISHED  TO  DEC 


/ 


z 

CO 

* 

2 

0 

ryj 

0 

* 

♦— 

UJ 

UJ 

^ x 

CO 

m 3 

♦—< 

•“H  JC 

w 

iC 

r> 

\ CO 

3 

x 

v a: 

• 

UJ 

\ 3 

*»«✓ 

*— 4 

\ r— 

X 

W 

r CD 

X 

c 

3 <1 

UJ 

3 

UJ  3 

I 

x 

3 

• 

< 

3 3 

*-• 

Z Z 

II 

x 

•—4 

X 

\ 

3: 

»—  ^ 

<■ 

v 

CO  3 

X 

z 

in 

O 3 

♦— t 

4C 

3 3 

4"*\ 

in 

3 

m 

UJ  3 

cP 

in 

3 

X 

TT 

►— 

O UJ 

< 

UJ 

>-  X 

2: 

O 

CO 

3 r— 

M 

►— 

* 

*-H 

CO 

►— 

V—/ 

f— 

3 = 

H- ■ 

C 

UJ 

0 

3 *• 

3 

CD 

CO 

3 

< 

*-H  \ 

CO 

►—4 

1 

CO 

3 

3 \ 

►— < 

w <-s 

♦ — 

►— 

z 

V 

w 

3 — • 

0 

z 

OJ  s 

3 

» — 

+ 

►— 

UJ 

CO 

X • 

3 

3 r 

v-^ 

♦—4 

►— 

C 3 

3 Xi 

CO 

1 

* 

0 

UJ 

i 3 

*—  •¥. 
(_)  * 


3 2 
C 


ryj 


lO 

u.  r> 


< 

<. 

X 

CO 

+ 

\ 

3 

O 

O 

• 

< 

•— 

>-N 

'— \ 

*0 

r— 

3 

►— « 

CO 

3 

X 

X 

m 

m 

3 

O 

w- 

*— 

r 

X 

•3 

3 

*— « 

0 

3 

CO 

3 

CO 

3 

X 

CO 

• 

« 

2 

*— 

3 

»— • 

CtL 

CO 

X 

J 

k— 

♦— 

'■"N 

• 

• 

3 

3 

CO 

' — ' 

3 

O 

♦ ■■ 

►— 

CO 

0 

3 

•— 4 

OJ 

C5 

CO 

cO 

►— « 

3 

CO 

*— 

3 

CO 

X 

»— 

—< 

CO 

3 

CO 

% 

V— 4 

3 

•— « 

►—1 

S~J • 

3 

O 

CO 

►— 

3 

<r 

— 

3 

v. 

*— 

r— 

*rr 

A. 

►— 

\ 

• 

3 

•♦t 

O 

►— 

N 

3 

< 

3 

3 

X 

co 

X 

3 

% 

3 

• 

**N 

— * 

iC 

< 

• 

X 

3 

r—t 

< 

3 

• — 

< 

3 

2 

X 

CO 

CO 

— • 

CO 

►— 

*— 

3 

3 

z: 

OJ 

CO 

~XL 

3 

II 

• — ' 

W»_ 

—4 

X 

\ 

X 

II 

>— 

z 

»— < 

II 

3 

3 

2 

11 

II 

z 

II 

3 

V 

~r 

% 

2 

X 

— «» 

c 

3 

*— 

3 

W 

— N 

CO 

cO 

—S 

»“> 

3 

*“N 

/-> 

X 

— « 

k. 

•— « 

< 

V. 

^r. 

r— 

— * 

v-4 

*— 

►— 

3 

CO 

3 

OJ 

— « 

*— * 

X 

m 

-O 

— • 

<j 

—4 

*— 

II 

w 

•— • 

«-c 

1 — 

3 

X 

X 

< 

3 

CO 

— 

II 

<a 

* 

w 

II 

% 

11 

OJ 

*-* 

II 

*: 

II 

»— < 

CO 

II 

11 

X 

T 

•—4 

— • 

►— 

CO 

:0 

— « 

*— 

» — 

“5 

►— 

4C 

X 

X 

»— < 

3 

*o 

w 

3 

— « 

4» 

<t 

CO 

►— 

Oj 

»— 

►— 

3 

liJ 

0 

3 

4C 

0 

11 

CO 

3 

♦—4 

3 

w 

f— 

z 

O 

II 

r— 

0 

3 

CO 

X 

X 

w 

>o 

>0 

0 

O 

— 

CO 

3 

O 

O 

*-s 

3 

. — 

0 

3 

3 

<c 

<L 

>T 

X 

x 

>P 

xi 

►— 

/ 

O 

CT 

•— 

t-H 

11 

wP 

11 

»— • 

X 

OO 

►— 

X> 

3 

3 

D' 

♦— 

X 

0. 

<1 

2 

w 

2 

>— ✓ 

v— * 

►— 

►— 

w 

3 

0.4 

<1 

3 

*— 4 

*— 

»— 4 

X 

O 

X 

11 

O 

3 

II 

O 

JC 

0 

c 

X 

> 

O 

O 

c> 

3 

< 

0 

W 

X 

3 

*— 

O 

*— » 

z 

O 

•— 4 

3 

*— < 

X 

O 

3 

3 

•— 

3 

*» 

3 

3 

3 

O 

*— 

3 

♦— 

3 

0 

3 

*—4 

5 

3 

►—4 

C 

X 

41 

3 

CO 

X 

O 

O 

in 

0 

O 

O 

O 

3 

3 

*n 

wP 

O 

3 3 

3 

cC 

C> 

c 

c 

3 

X 

59 


THIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
FROM  COPY  X0C.bC 


co 

o 

< 

u_ 

2 

v 

14 

►— t 
^ <“N 

•“«  \ 

> ’ * 
CO  o 

►—  —I 

O <1 


CO 

a: 

uJ 


51 

< 

a: 


* 

I— 

m 

2 

x 

3 

O 

o 

X 

o 

X 

♦— 

o 

o 

o 

o 

o 

— « 

<. 

o 

u. 

OJ 

■•l 

» 

►— 

s 

2 '-n 

— 

UJ 

w 

O — 

CO 

X 

X 

►— 

X 

3 lO 

UJ 

<■ 

UJ  * 

CO 

t— 

r 

CO  o 

*— 4 

< 

•• 

CO 

< — * 

o 

w 

O 

X 

3 

X)  C 

o 

o 

3 

w 

OJ 

u. 

z 

—1 

3 

CO  J~> 

4 

4- 

3 

<■ 

HH  *fc 

X 

3 

>■ 

co  x 

rO 

OJ 

X 

U_ 

x ^r 

* 

4 

•» 

CO 

3 — • 

►— 

3 4 

X 

CO 

• — 4 

<t  * 

UJ 

3 — 

• • 

t— 

CO 

2 X 

CO 

3 OJ 

3C 

z 

>- 

— < V, 

4—4 

X *. 

o 

UJ 

3 

CO  = 

w* 

^ ►— 

-J 

♦— y 

< 

t—  >-  CO 

*: 

*“•  3 

_J 

o 

2 

3 h-  a: 

3 

* CO 

o 

♦— < 

< 

< — * 3 

4- 

3 — 

u. 

u_ 

rO 

3 > — 

s-/  V— ✓ 

u_ 

>- 

2—3 

<-*. 

3X3 

CO 

UJ 

►— 

% ►— 

OJ 

4 U.  3 

X 

o X 

if 

►—4 

•—»>—«  u. 

/-n  4 3 

UJ 

3 v 

> 

II  CO  : 

» — 

— OJ  X 

t— 

c 

* 

2 X 

3 

/-N  W -N 

UJ  — 

^-s 

3 — 

►— 

% 3 J"* 

CO 

OJ  X Ou 

X x 

— X 

3 3 

3 

*— « 4 

— CO  s 

•—4 

* ""S  *. 

<1  K 

to  *• 

3 = 

% >*-N 

CO 

3 a: 

v— ' 

•—  x 3 

a:  = 

W <“N 

3 «. 

•—*  X 

2 

- 3 

XL 

3 3>-' 

<f  rO 

— >0  CO 

X X 

UJ 

CO  OJ  H- 

Lu 

CO  1 3 

£X 

II  • — 

in 

3 

CO 

r-  H LlJ 

— 4 

— — 4 

3 " 

3 • x 
f—  o 


"5  OJ 

— ID 

“5  * 

% X 

— *0 


2 

UJ 


3 

3 

> 


X 

UJ 


20 


O 

Oj 

3 


3 

X 


= X 
< 
H-  X 
UJ  < 
CO  CL 


3 - — X 3 


o Oj 
o w 
o x 
O '—N 
C3  X 
4 3 
^ I 


3 

3 

3 


■«  —X 

OJ  v 


OJ 


<r 

OJ 

XL 

rO 

3 

X 

*o 

3 

3 

3 

*— 

t— 

X 

OJ 

CO 

CO 

CO  -> 

3 

X 

CL 

3 

x 

CO 

JL. 

V 

3 

3 

►— 

<x 

' — - 

co 

3 

< 

X 

v 

• — ' 

3 

X 

»— 1 

M ' — ’ 

3 

X 

s 

— 

X 

3 

X 

— * 

3 

3 

fO 

►—• 

2 

CO 

q 

X 

3 

4 

3 

3 

- — ' 

^ 3 

♦— « 

O 

t — 

3 

OJ 

t— 

* 

<1 

«. 

2 

*— 4 

r 

3 

<1 

• 

X 

^ 4 

W 

- — ' 

3 

X 

CO 

•— < 

*• 

3 

z 

3 

«— < 

o 

•— » 

—4 

r 

» 

co 

— « 

3 

3 

3 O 

►— 

z 

o 

2 

J^ 

3 

s 

•— t 

2 

X 

II 

w 

UJ 

•— < 

•w 

2 

I 

4 O 

> — 

•> 

— 

k 

— 

—4 

3 

■— » 

V 

k. 

<1 

X 

►— 

—4 

X 

3 

w 

— 

V-/ 

Oj  Ol 

OJ 

4- 

to 

X 

— 

c? 

•• 

C 

LO 

X 

z 

>o 

UJ 

NO 

X 

3 

3 

*-4 

II 

II 

^ II 

a 

r 

3 

o- 

X 

r 

it 

O' 

X 

X 

O' 

X 

II 

O' 

X 

3 

CO 

X 

X 

3 

CO 

II 

/-\ 

X — ' 

V 

«-« 

X 

— 

• — < 

— 

•> 

X 

>C 

*— 4 

«-4 

2 

»— * 

•> 

X 

3 

1 

►—4 

"O 

o. 

X to 

r 

JO 

» — 

in 

X 

lO 

w 

f— 

Si 

W 

*o 

< 

x> 

s-' 

V— « 

3 •* 

• • 

W 

♦— 

3 

►— 

r 

o 

w' 

t— 

3 

*— 

•■H 

o 

1— 

o 

s_> 

t— 

3 

X 

XL 

o 

"O 

4 -D 

3 3 

< 

3 

3 

<x 

OJ 

UJ 

<1 

3 

3 

<r 

rO 

3 

< 

3 

x> 

UJ 

«u 

3 

X 

3 

• 4 

W4 

*—* 

3 

t— 

X 

f— 

>■ 

— > 

— 

X 

K— 

X 

*-< 

t— 

5. 

*— 

— « 

►“ 

>: 

H-* 

3 

II 

CO 

CO 

co 

;r 

— 

a: 

— 

►— < 

X. 

*— • 

X 

*-H 

X 

>— i 

X 

3 

*— < 

X 

3 

II 

3 

2 

2 

2 

3 

a 

3 

2 

a: 

3 

o 

X 

o 

2 

X 

o 

3 

X 

3 

CL 

3 

X 

3 

X 

3 

3 

3 

3 

3 

3 

£ 

u. 

•— « 

a_ 

3 

£ 

u. 

*— « 

3 

3 

3 

X 

3 

2 

3 

X 

3 

3 

•3 

CO 

CO 

CO 

4 

a: 

« 

a 

4 

3 

4 

4 

X 

a. 

3 

o 

o 

O 

OJ 

OJ 

=J 

lO 

to 

CJ 

O' 

c 

c 

3 

O' 

— — 

O' 

3 3 3 

O' 

— 

X 

c 

c 

3 

— 

— 

6 0 


150  *RITt(5, 151)  KI, (SfcNS( J,KI), J=1,NFACTS) 

151  FURKAT (/,5X, "K”, II ,bX,5(G12.b,3X) ) 


THIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
FROM  COF7  F'JRMSHLL  TO  uLC  


SOFTWARE  LIFE  CYCLE  COST  MODEL 


8 DATA  SETS  WERE  USED. 

THE  FOLLOWING  FACTORS  WERE  CONSIDERED:  X HOL 

PROG  GUAL 
DEV  ON  1 G T 
MOD  DESIGN 

the  fitied  parameters  follow: 


DATA  SE1 

K1 

K 2 

K 3 

1 

.689688 

.520291L-03 

1.8/500 

2 

2.2816/ 

.2978820-03 

10.8J70 

3 

2.20299 

.2551 02E-02 

.558000 

8 

.7977/0 

. 38  7222E-02 

.278000 

THE  DERIVED 

MODEL  COEFFICIENTS 

F OLLOw ; 

factor 

AI 

HI 

Cl 

X HOL 

2.22068 

-. 203717 E -03 

12.9887 

PROG  DUAL 

-. 128995 

. 5 1 BB52E-0  8 

-.325788 

DEV  ON  TGT 

8 . fa  7 B 7 0 

-.  18258^2-02 

9.69350 

MOD  DESIGN 

8 . 8 7 2 fa  1 

-.599397E-03 

18.1270 

62 


L 


■■Mi 


2 

2 

O 

0 

»-H 

»— * 

CO 

ru 

in 

■y 

CO 

ru 

O' 

0 

UJ 

cy 

0 J 

uJ 

ao 

>n 

cy 

• 

0 

nj 

r-» 

r^- 

• 

0 

aO 

r"- 

X 

LU 

m 

O' 

OJ 

uJ 

cr 

O' 

ru 

-J 

X 

in 

* 

X 

-J 

0 

in 

rvj 

X 

O 

0 

• 

r-* 

• 

0 

0 

• 

• 

>- 

X 

CO 

• 

oj 

>- 

X 

rv 

• 

o 

0 

UJ 

UJ 

Ll. 

u. 

NH 

-J 

»— 

_J 

»— 

CD 

CD 

X 

h- 

X 

t- 

►— 

X 

in 

►— 

tr 

in 

rH 

2 

2 

*-« 

0 

O' 

2 

2 

0 

x 

O 

0 

O 

O' 

nj 

O' 

O 

O 

cy 

0 

X 

x 

a 

ru 

X 

cr 

x» 

O' 

>■ 

^y 

O' 

> 

NO 

0 

OJ 

0 

uJ 

• 

• 

• 

0 

UJ 

• 

• 

0 

3 

rH 

0 

3 

»—< 

NO 

• 

rvj 

ru 

2 

2 

0 

0 

» H 

«— » 

0 

O 

O 

0 

O 

0 

UJ 

_J 

1 

1 

UJ 

-J 

« 

t 

10 

<. 

uJ 

uJ 

CO 

< 

UJ 

UJ 

c 

X 

0 

r- 

0 

<c 

3 

ec- 

ru 

X 

X 

3 

in 

ru 

ru 

X 

£■*■, 

ru 

ru 

NO 

— « 

0 

O' 

O' 

rO 

ro 

CO 

CD 

0 

*0 

— ♦ 

CO 

3 

cc 

OJ 

M 

O 

r\j 

ru 

in 

►— « 

O 

in 

*-« 

00 

a: 

— * 

X 

>0 

CO 

or 

•0 

>- 

a. 

• 

• 

• 

>- 

X 

• 

» 

• 

-J 

1 

1 

l 

-J 

• 

1 

l 

<1 

< 

2 

2 

<t 

<x 

>- 

>- 

f— 

*— 

►—* 

CO 

co 

>• 

X 

ru 

O 

oj 

> 

X 

0 

NO 

NO 

0 

cr 

ru 

0 

— « 

— « 

NO 

►— 

— _j 

n 

-0 

►— 

r—  -J 

O' 

O 

O' 

*— • 

C_J  O 

no 

cy 

O' 

M 

(_)  O 

r^- 

NO 

CO 

<1  X 

— * 

cy 

X 

CO 

<t  X 

NO 

cy 

2 

IL. 

• 

oj 

• 

2 

U_ 

>0 

cy 

UJ 

OJ 

• 

ru 

uJ 

• 

• 

• 

CO 

CO 

ru 

a 

X 

►— 

UJ 

►— 

UJ 

UJ 

►— 

UJ 

t— 

co 

uJ 

OJ 

ro 

CO 

UJ 

ru 

NO 

X 

X 

* 

<x 

< 

< 

< 

♦— 

a* 

a: 

< 

< 

<x 

< 

0 

CL 

0 

a 

63 


/ 

THIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
FROM  COLI  FURNISHES  TO  DLC 


z 

0 

►— < 

CO 

OJ 

co 

UJ 

0 

cc 

OJ 

• 

0 

S\ 

a 

h- 

UJ 

0 

>0 

O 

0 

00 

OJ 

o 

0 

• 

— • 

• 

>- 

X 

« 

in 

u 

UJ 

Ll 

*— « 

3 

►— 

X 

»— 

►— 

O 

in 

z 

z 

*-1 

CO 

v0 

3 

0 

O 

r*- 

x 

X 

X 

cy 

in 

>• 

>0 

n 

o 

aJ 

• 

• 

o 

O 

• 

rO 

OJ 

z 

o 

o 

O 

0 

UJ 

-J 

f 

1 

CO 

< 

aJ 

UJ 

<. 

3 

OJ 

>0 

OJ 

CD 

3 

cy 

in 

m 

00 

O 

CO 

LD 

»-* 

w ■« 

O 

►-H 

O 

in 

nO 

OJ 

CO 

a 

^r 

•H 

w-t 

>- 

CL 

• 

• 

• 

3 

l 

1 

1 

<r 

2: 

<1 

• t 

>- 

O 

b- 

1 

b-i 

CO 

UJ 

> 

3: 

r-^ 

CO 

X) 

*— i 

3 

~x> 

O' 

>0 

t— 

*—  -1 

^y 

••x* 

*— * 

U O 

OJ 

tn 

CO 

CO 

c X 

0 

m 

z 

Ll. 

CO 

sC 

• 

UJ 

• 

• 

Ti- 

CO 

m 

x 

►— 

UJ 

UJ 

►— 

CO 

UJ 

rw 

ro 

X 

* 

iC 

<1 

<r 

h~ 

cr 

< 

< 

0 

a. 

z 

CD 

b* 

CO 

Ty- 

x 

in 

uJ 

co 

•— < 

• 

0 

X 

CO 

m 

UJ 

OJ 

vO 

0 

-J 

0 

m 

<H 

• 

0 

0 

• 

x0 

>- 

X 

• 

— t 

0 

UJ 

u_ 

►— * 

-J 

CD 

X 

f— 

♦— 

X 

in 

cC 

z 

z 

vO 

*H 

xC 

0 

0 

0 

O 

xO 

X 

r^- 

00 

ro 

> 

X 

• 

0 

LU 

• 

OJ 

0 

ro 

• 

<—4 

OJ 

z 

0 

•-« 

0 

O 

UJ 

-J 

1 

CO 

< 

UJ 

< 

3 

>c 

O' 

X 

X 

e 

m 

■O 

in 

0 

*— 1 

X 

co 

CD 

>0 

— • 

ro 

►— < 

O 

0 

0 

CO 

CO 

3: 

•—4 

▼—4 

>- 

CL 

• 

• 

• 

_i 

1 

1 

l 

<1 

z 

< 

>- 

0 

t— 

1 

►— < 

CO 

UJ 

;» 

X 

OJ 

0 

in 

OJ 

X 

►— 

3 

x 

OJ 

O C 

CO 

ro 

CO 

< X 

30 

X 

• 

z 

a. 

• 

fO 

i n 

UJ 

• 

rH 

CO 

X 

X 

►— 

3 

UJ 

u • 

CO 

UJ 

OJ 

ro 

X 

*: 

< 

X 

< 

< 

0 

X 

The  FOLLOWING  PREDICTED  PARAMETERS  WERE  computed: 


VITA 


William  H.  Walker  IV  was  born  on  13  March  1950  in 
Minneapolis,  Minnesota.  He  graduated  from  high  school  in 
Portland,  Oregon,  in  1968  and  attended  the  United  States 
Air  Force  Academy  from  which  he  received  the  degree  of 
Bachelor  of  Science  with  two  majors,  computer  science  and 
mathematics,  in  June  1972.  Upon  graduation,  he  received  a 
commission  in  the  USAF  and  completed  navigator  training  in 
April  1973*  He  then  served  as  a C-141A  airlift  navigator, 
instructor  navigator,  and  flight  examiner  navigator  with 
the  14th  Military  Airlift  Squadron,  Norton  AFB,  California. 
He  was  selected  to  enter  the  School  of  Engineering,  Air 
Force  Institute  of  Technology,  in  June  1977* 

Permanent  address:  2120  Highway  101  North 

Rockaway,  Oregon  97136 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (When  Dale  Entered) 


READ  INSTRUCTIONS 


REPORT  DOCUMENTATION  PAGE 


BEFORE  COMPLETING  FORM 


3.  RECIPIENT’S  CATALOG  NUMBER 


STgOVT  ACCESSION  NO 


5.  TYPE  OF  REPORT  & PERIOD  COVERED 


4 TITLE  (and  Subtitle) 


k*  1 vG-Aoh 


6 PERFORMING  ORG.  REPORT  NUMBER 


7.  AUTHOR(s) 


alicar  IV 


9 PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 


Kir  orce  Institute  o 
ri  ht-rattercon  k ■, 


echnolo  y(n 
Ohio  45433 


o ae  .ir  .development  Center  (.uidC 
riff  is?  0 , Q>.7  iorlr  13441 


15.  SECURITY  CLASS,  (of  this  report) 


14  MONITORING  AGENCY  NAME  ft  ADDRESS  (if  different  from  Controlling  Office) 


DECLASSIFICATION  DOWNGRADING 
SCHEDULE 


16-  DISTRIBUTION  STATEMENT  (of  this  Report) 


• •'roved  for  outlie  release j 


io tributio.n  unlimited 


17  DISTRIBUTION  STATEMENT  (of  the  abstract  entered  in  Block  20,  if  different  from  Report) 


josepK  p./Tnrps.^j,  UsAr 

jir*ct?jf’  of  Information 


19  KEY  WORDS  f Continue  on  reverse  side  it  necessary  arid  identify  by  block  number J 


rife  Jyi 
odelin 


20  ABSTRACT  ^Continue  on  reverse  side  if  necessary  and  identify  by  block  number.) 


hi7  report  describee  the  development  0"  a software  life  cycle 
cootin  • node!.  he  modal  reduces  life  cycle  co^t  to  a function 
of  three  naraiaa fcere  which  are,  in  turn,  functions  of  ? number  of 
factors;  that  iejeribe  the  Eoftv-p.re  syrte  :.,  i\  cte"-by-c  top 
al  orithm  is  presented  for  buildin  the  model  fro-'  re^  data.  he 

model  in  exercised  as  an  example  *ith  s smell  amount  of  data, 
he  mopt  salient  factor?  era  •'elected  by  woe  of  ron^itivity 


EDITION  OF  I NOV  65  IS  OBSOLETE 


UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  THIS  PAGE  rHTi.n  Data  Entrrrd) 


SECURITY  CLASSIFICATION  of  THIS  PAGECWfren  Data  Entered) 


analysis.  irief  descriptions  of  nans  enent  application)?  and 
recomendr  1 .•  c,  zre  arorented.  \pp«ndic«r  describe  MURpla  do.tr 
and  tv/o  computer  pro ’rams  unad  to  develop  tho  rodel. 


